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1.0  Scope 

1.1  Identification.  This  report  is  the  final  report  discussing  the  Automated  Tactical 
Aircraft  Launch  and  Recovery  System  (ATALARS)  upgrades  to  the  Enhanced  Joint 
Tactical  Information  Distribution  System  (JTIDS)  System  Exerciser  (EJSE)  as  well  as 
recommendations  for  future  Air  Traffic  Control  (ATC)  study.  This  report  is  prepared 
under  contract  F19628-87-C-0254,  and  in  accordance  with  the  guidelines  contained  in 
DI-S-359I/A. 

Hereinafter,  the  EJSE  and  its  components  refer  to  the  Army  and  Navy  Configured 
EJSE  baseline  developed  under  contract  number  DAAB07-87-C-A043.  The  Display 
Group  (DG)  portion  of  EJSE,  serving  as  v  model  for  the  ATALARS  Ground  Control 
Unit  (GCU)  is  hereinafter  referred  to  as  tne  GCU.  The  Interactive  Simulation  Group 
(ISG)  portion  is  hereinafter  referred  to  as  the  ISG. 

1.2  Purpose.  The  EJSE  is  a  transportable  system  for  exercising  and  monitoring  par¬ 
ticipants  in  a  JTIDS  communications  network.  The  algorithms  described  are  designed 
for  use  in  the  EJSE  architecture.  The  intent  was  to  prove  the  feasibility  of  using  JTIDS 
as  the  ATALARS  data  link  by  demonstrating  the  use  of  ATC  algorithms  in  the 
closed-simulation  environment  of  the  EJSE.  To  this  end,  this  report  describes  the 
design  and  implementation  of  these  ATC  algorithms  in  the  EJSE  and  upgrades  to  the 
EJSE. 

The  modifications  to  the  EJSE  described  in  this  report  were  designed  and  developed 
in  support  of  the  ATALARS  Proof  of  Concept  demonstration  being  developed  under 
contract  F19628-87-C-0254,  which  constitutes  Phase  II  of  a  Small  Business  Innovation 
Research  (SBIR)  contract  resulting  from  Solicitation  No.  AF87-  032. 

The  Ground  Control  Unit  Computer  Program  (GCUCP)  is  the  upgrade  to  the  Display 
Group  (DG)  of  the  EJSE  to  support  the  ATALARS  Proof  of  Concept  demonstration. 
The  purpose  of  the  GCUCP  was  to  model  an  ATALARS  Ground  Control  Unit  that 
implements  ATC  algorithms  which  identify  and  resolve  ATC  problems  in  a  military 
and  civil  airspace  environment  and  provide  resolution  directives  via  JTIDS  messages 
transmitted  over  a  JTIDS  data  link. 

For  this  study,  the  GCUCP  demonstrated  the  feasibility  of  using  JTIDS  as  the 
ATALARS  data  link  through  participation  in  ATALARS  scenarios  conducted  in  the 
closed  simulation  environment  of  the  EJSE. 

The  Interactive  Simulation  Group  Computer  Program  (ISGCP)  provided  the  closed 
simulation  environment  needed  to  produce  simulated  elements  and  create  conditions 
of  path  divergence,  separation  violation,  and  diversion.  The  ATC  algorithms  residing 
in  the  GCUCP  resolve  the  violations  and  send  corrective  action  to  the  ISGCP  which 
in  turn  responds  by  altering  the  simulated  elements  accordingly. 
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1 J  Introduction.  The  upgrades  described  in  this  report  were  designed  and  developed 
in  support  of  the  ATALARS  Proof  of  Concept  demonstration  being  developed  under 
the  above  mentioned  contract.  They  use  accepted  methodologies  implemented  in 
current  ATC  problem  resolution  during  military/civil  airspace  management.  Their 
design  was  strictly  tailored  to  the  EJSE  architecture  with  consideration  of  its  Central 
Processing  Unit  (CPU)  capabilities  and  memory.  The  simplifying  assumptions  as 
described  herein  are  consistent  with  the  scope  of  the  current  contract. 

In  general,  the  EJSE  employed  advanced  ATC  algorithms  and  a  dynamic  scenario 
database  to  demonstrate  how  JTTDS  could  be  used  to  manage  ATC  problems  in  a 
military  and  civil  environment.  Through  implementation  of  the  Phase  II  ATC  Algo¬ 
rithms,  the  EJSE  resolved  problems  regarding: 

a.  Path  Conformance 

b.  Separation  Assurance 

c.  Diversion 

Missed  Approach,  although  described  in  the  Phase  II  proposal,  was  deleted  from  the 
Phase  II  demonstration  due  to  the  processing  burden  required  by  the  more  frequent 
transmissions  and  processing  of  the  Close  Control  and  Landing  messages  offered 
through  JTIDS.  As  such,  the  Phase  II  demonstration  depicted  aircraft  under 
ATALARS  control  up  to  the  Initial  Approach  Point  (LAP)  of  their  destination  airbase, 
at  which  point  the  ATALARS  GCU  generated  a  JTIDS  handover  message  to  relinquish 
control  of  the  aircraft  to  an  arrival  controller. 

The  ATC  problems  described  above  are  detected  and  resolved  through  the  following 
set  of  ATC  Algorithms: 

a.  Path  Conformance  Alert  (PCA) 

b.  Flight  Path  Generation  (FPG) 

c.  Conflict  Avoidance  (CA) 

d.  Hazard  Alert  (HA) 

e.  Hazard  Resolution  (HR) 

f.  Diversion  (DIV) 

Table  I  presents  a  cross  reference  matrix  of  ATC  Algorithms  to  ATC  Problems.  A 
description  of  each  of  these  algorithms  is  contained  in  Section  3.0  of  this  report. 
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TABLE  I 

ATC  ALGORITHMS  TO  ATC  PROBLEMS  CROSS  REFERENCE  MATRIX 


The  ATC  algorithms  are  totally  contained  within  the  GCU  component  of  the  EJ SE  and 
are  written  in  the  FORTRAN  77.  The  ISG  is  present  in  the  EJSE  to  simulate  elements 
in  the  ATALARS  control  area  which  can  acknowledge  and  react  to  ATC  directions 
resulting  from  the  GCU  algorithms.  The  design  and  description  of  the  ISG  and 
non-algorithmic  functions  of  the  GCU  are  contained  in  Interim  Technical  Reports  1, 
2,  &  3  submitted  earlier  under  this  contract. 

In  general,  the  GCUCP  upgrade  was  comprised  of  ATC  Algorithms,  automated  JTIDS 
message  capability  and  associated  databases.  A  complete  GCUCP  base  line  is  con¬ 
tained  in  the  Computer  Program  Product  Specification  of  the  Display  Processor 
Computer  Program  of  the  Army/Navy-Configured  EJSE,  W80YBY87C3003,  Type  C5. 

The  ISGCP  upgrade  was  comprised  of  the  transformation  of  the  Simulation  Tape 
Generation  Program  (STGCP)  from  an  off-line,  non-real  program  into  a  real-time,  on¬ 
line  program  which  simulates  and  reacts  to  ATC  problems  at  the  GCUCP.  A  complete 
identification  of  the  baseline  STGCP  in  contained  in  the  Computer  Program  Product 
Specification  of  the  Simulation  Tape  Generation  Computer  Program  of  the 
Army/Navy-Configured  EJSE,  W80YBY87C3001,  Type  C5. 

1.4  Organization  and  Content.  This  report  is  structured  as  follows: 

a.  Section  1.0  provides  a  scope  of  the  report 
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b.  Section  2.0  identifies  the  referenced  documents  in  support  of  this 
report 

c.  Section  3.0  is  a  description  of  each  ATC  algorithm  employed  in  the 
EJSE  and  a  description  of  the  database  showing  the  structure  and 
interrelationship  of  data  base  tables  in  the  EJSE 

d.  Section  4.0  is  the  description  of  the  new/modified  functions 
applicable  to  the  ISG 

e.  Section  5.0  provides  the  results  and  recommendations 

f.  Section  6.0  a  list  of  acronyms  used  in  this  report 

g.  Section  7.0  is  a  glossary  of  ATC  definitions  as  they  pertain  to  this 
report. 
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2.0  REFERENCED  DOCUMENTS 


Contract 

F19628-87-C-0254 
CDRL  Sequence  No.  403 


Contract 

F19628-87-C-0254 
CDRL  Sequence  No.  405 


Contract 

F19628-87-C-0254 
CDRL  Sequence  No.  409 


W80YB  Y  87C3003 


19  April  1989 


2  November  1989 


ATALARS  Air  Traffic  Control 
Algorithm  for  the  Phase  II  Proof 
of  Concept  Demonstration 
Interim  Technical  Report  1. 

ATALARS  Data  Base  Design  for 
the  ATC  Algorithms  of  the 
ATALARS  RISE  Interim 
Technical  Report  2. 


22  November  1989  Interaction  Simulation  Group  for 
the  ATC  Algorithms  of  the 
ATALARS  EJSE  Interim 
Technical  Report  3. 


7  April  1989 


W80YBY87C3001 


7  April  1989 


1  January  1986 


15  June  1981 


July  1986 


December  1986 


Display  Processor  Computer 
Program  of  the  Army  Configured 
EJSE  and  the  Navy  Configured 
EJSE,  Type  C5  (Draft). 

Simulation  Tape  Generation 
Computer  Program  of  the  Army 
Configured  EJSE  and  the  Navy 
Configured  EJSE,  Type  C5  (Draft). 

JINTACCS  JTIDS  TIDP  (Test 
Edition  RE VI:  Volume  II - 
Interface  Specifications,  Fixed 
Word  Format  (Part  1  through  4) 

(U). 

JINTACCS  JTIDS  TIDP  (Test 
Edition):  Annex  A  -  Minimum 
Implementation  (U). 

JINTACCS  JTIDS  Technical 
Interface  Design  Plan  -  Test 
Edition  (TIDP  -  TE),  Revision  1, 
Change  1. 

US  Air  Force  TIDP  Interim 
Change  Notice  Package  for  the 
following  ICPs*: 
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ICP 

ICP 

ICP 

32.4 

164.2 

193.1 

34.1 

167.3 

194.2 

44.2 

169.1 

195.1 

97.2 

171.1 

197.0 

127.3 

172.2 

200.1 

138.3 

176.2 

200.1 

162.2 

179.4 

202.1 

*  Number  after  decimal  point  is  the 
change  number  of  the  ICP. 


ICP 

203.1 

204.1 

206.1 

207.2 

209.3 
212.1 
258.2 
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3.0  ALGORITHMS  AND  DATABASE  ITEMS. 

Descriptions  of  the  automated  ATC  algorithms  employed  in  ACSI’s  Phase  II  Proof  of 
Concept  Demonstration  for  ATALARS  are  contained  in  the  subparagraphs  that  follow 
(Refer  to  section  7.0  for  ATC  definitions).  The  thresholds  which  invoke  path  confor¬ 
mance  and  separation  assurance  violations  are  operational  parameters  of  the  GCU 
system.  The  thresholds  stated  in  this  report  are  the  preset  values  listed  in  Table  II.  They 
may  be  changed,  however,  before  or  during  an  ATALARS  scenario.  FORTRAN 
77-defined  variables  are  in  upper  case  throughout  this  report,  e.g.  SAPTPCAL. 

The  database  items  associated  with  the  algorithms  consist  of  activation  switches  and 
threshold  parameters.  A  full  listing  of  the  variables  along  with  their  limits  is  listed  in 
Table  III. 

3.1  Path  Conformance  Alert  (PCA)  Algorithm.  PCA  is  a  periodic  task  that  continually 
monitors  each  ATALARS  controlled  aircraft  within  the  ATALARS  control  area.  If  an 
aircraft  deviates  from  its  flight  plan  by  more  than  SAPTPCAL  feet  in  altitude  or  by 
more  than  SAPTPCRG  nautical  miles  laterally,  a  non  conformance  alert  is  displayed 
and  PCA  requests  the  FPG  algorithm  to  resolve  the  non  conformity  by  generating  a 
new  flight  plan. 


TABLE  II 

ATALARS  OPERATIONAL  PARAMETERS 


ATC  PROBLEM 

OPERATIONAL 

PARAMETER 

PRESET  CRITERIA 
OR  VALUE 

Path  Conformance 

Altitude 

300  feet 

Lateral  Range 

2  nautical  miles 

Active  Switch 

ON 

Monitor  Rate 

30  seconds 

Conflict  Avoidance 

Altitude 

Message  Value 

1 

Lateral  Range 

Threat  Dependent 

Active  Switch 

ON 

1  Separation  Assurance 

Altitude 

500  feet 

j 

Lateral  Range 

3  nautical  miles 

i 

Active  Switch 

ON 
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TABLE  III 

AT  ALAR  S  OPERATIONAL  PARAMETER  VALUES 


PARAMETER 

DEFAULT 

VALID  RANGES 

f - 

SAPTPCAL 

300' 

100’ -5000’ 

SAPTPCRG 

2nm 

2nm  - 10  nm 

j 

SAPTPCIN 

ON  =  1 

0-1  | 

SAPTPCRT 

' 

30  secs 

15  secs  - 180  secs  | 

1  SAPTCFIN 

I 

11 

z 

O 

0-1 

; 

SAPTHZAL 

! 

500' 

500'  -  5000' 

1 

SAPTHZRG 

3nm 

2nm  -  lOnm 

!  SAPTSAIN 

| 

ON  =  1 

0-  1 

|  SAPTAEN 

ON  =  1 

0-1 

The  PCA  is  enabled  for  each  ATALARS  aircraft  every  SAPTPCRT  seconds  if  the 
operator  has  enabled  (  =  ON)  the  Path  Conformance  Indicator  (SAPTPCIN).  The 
default  values  for  SAPTPCAL  is  300  feet,  SAPTPCRG  is  2  miles,  and  SAPTPCRT  is 
30  seconds  and  are  modifiable  by  the  operator  at  the  GCUCP.  The  flight  path  of  an 
aircraft  under  ATALARS  control  is  considered  in  violation  if  its  deviation  exceeds  any 
of  these  limits.  The  time  to  perform  path  conformance  is  contained  in  a  Path  Confor¬ 
mance  monitor  table.  This  table  contains  an  entry  for  each  aircraft.  The  periodic 
processor  function  of  the  GCU  examines  the  table  periodically  (at  least  every  second). 
When  a  time  to  perform  path  conformance  is  reached,  the  PCA  algorithm  is  invoked. 
PCA  uses  the  altitude,  latitude,  longitude  and  time  from  the  current  location  and 
identity  for  that  particular  element  message.  If  the  message  time  coincides  with  a 
waypoint  time  in  the  aircraft’s  flight  plan  table,  then  the  altitude,  latitude  and  longitude 
of  the  waypoint  are  used  in  the  check.  Otherwise  the  values  of  altitude,  latitude  and 
longitude  used  in  the  check  are  linearly  interpolated  form  the  values  of  these 
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parameters  at  the  waypoints  whose  time  immediately  precedes  and  follows  the  message 
time.  In  either  case,  the  values  of  the  parameters  obtained  from  the  flight  plan  table 
are  its  “assigned”  values.  (See  figure  1)  The  aircraft’s  altitude  must  be  within  SAPTP- 
CAL  feet  of  its  assigned  altitude;  the  aircraft’s  lateral  position  must  be  within  a 
SAPTPCRG  nautical  mile  radius  of  its  assigned  position.  If  path  conformance  is  not 
met,  the  FPG  algorithm  is  called.  Path  conformance  for  this  aircraft  will  be  suspended 
while  path  deviation  is  being  resolved. 

3.2  Flight  Path  Generation  (FPG)  Algorithm.  When  invoked  as  a  resolution  to  a  Path 
Conformance  violation,  Diversion  or  Separation  Assurance,  FPG  generates  a  conflict 
free  path  (if  SAPTCFIN,  Conflict  Avoidance  Indicator,  is  enabled  ( =  ON))  and  a 
hazard  free  path  for  the  first  thirty  seconds  of  the  new  flight  path  (if  SAPTSAIN, 
Separation  Assurance  Indicator  is  enabled  ( =  ON)). 


ALTITUDE 


Altitude  of  Way  point  n  +  1 
(from  Flight  Plan) 


Altitude  profile  interpolated 
linearly  between  way  point 
n,  n  +  1  altitudes 


300' 


300’ 


300' 


300' 


Altitude  of  Way  point  n 
(from  Flight  Plan) 


Shaded  area  is  altitude  conformance  area 
for  time  between  way  points  n,  n  + 1 


TIME 


Figure  1.  Altitude  Conformance  Envelope 
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a.  The  assumptions  used  in  the  algorithm  are  as  follows: 

1)  The  flight  path  of  an  aircraft  will  consist  of  a  series  of  straight 
line  segments  joining  projected  waypoints. 

2)  On  each  line  segment,  any  changes  in  the  aircraft’s  latitude 
and  longitude  will  be  linear  with  respect  to  time.  In  our 
ATALARS  demonstration,  the  ground  speed  will  be  constant 
along  each  line  segment. 

3)  Magnitude  of  jump  discontinuities  in  ground  speed  at  way- 
points  will  be  small. 

4)  Any  changes  in  the  aircraft’s  altitude  will  be  linear  with 
respect  to  time  along  each  segment.  Changes  in  this  rate  at 
waypoints  will  be  instantaneous,  however,  they  will  not  exceed 
4000  feet  per  minute  in  magnitude.  The  climb/descent  profile 
is  determined  by  the  difference  between  waypoint  altitudes 
divided  by  the  elapsed  time. 

b.  The  FPG  Algorithm  operates  in  three  phases: 

1)  Phase  1 

The  current  position  of  the  aircraft  is  extrapolated  4  seconds 
into  the  future.  It  is  assumed  that  the  aircraft  will  continue 
to  travel  at  a  constant  accelerationdeceleration  rate,  its  course 
of  travel  will  not  change,  and  the  aircraft’s  althude  climb/descent 
rate  will  not  change.  This  point  will  become  a  new  waypoint  in  the 
flight  plan.  The  aircraft  will  continue  to  travel  through  all 
remaining  waypoints  to  the  IAP  with  the  only  change  at  each 
waypoint  being  the  time  to  reach  each  respective  waypoint. 

2)  Phase  2 

If  the  Conflict  Avoidance  Indicator  (SAPTCFIN)  is 
enabled  ( =  ON),  the  newly  generated  path  described  above 
is  checked  to  assure  that  the  path  is  conflict  free  to  its  IAP. 

If  it  is  not  conflict  free,  additional  waypoints  are  inserted 
to  the  flight  plan  and  waypoint  times  are  recalculated. 

See  Section  3.3  for  more  details. 

3)  Phase  3 

If  the  Separation  Assurance  Indicator  (SAPTSAIN)  is  enabled 
(  =ON),  the  newly  generated  path  described  in  Phases  1  and  2 
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is  checked  to  be  hazard  free  for  the  first  thirty  seconds  of  its  new 
path.  If  the  newly  generated  path  is  not  hazard  free,  additional 
waypoints  are  inserted  into  the  flight  path  to  resolve  the  hazard 
situation.  See  Sections  3.4  and  3.5  for  more  details. 

In  the  instances  the  Conflict  Avoidance  Indicator  (SAPTSAIN)  and  the  Separation 
Assurance  Indicator  (SAPTSAIN)  are  enabled,  Phases  2  and  3  are  continually  checked 
until  the  pass  through  the  two  checks  produces  no  new  waypoints.  At  this  time  the  flight 
path  is  both  conflict  free  (to  its  IAP)  and  hazard  free  (for  thirty  seconds). 

3.3  Conflict  Avoidance  (CA)  Algorithm.  CA  is  called  by  FPG  algorithm  to  determine 
when  a  generated  path  conflicts  with  a  restricted  fixed  airspace.  The  new  path  is 
generated  in  such  a  way  that  the  aircraft  will  not  penetrate  the  restricted  airspace.  The 
volume  of  restricted  fixed  airspace  is  defined  to  be  a  cylindrical  area  around  a  land 
point/track  with  the  lateral  range  being  ten  or  twenty  miles,  depending  on  threat  type 
with  the  vertical  range  being  from  ground  level  (0  ft.  msl)  to  the  elevation  in  the  land 
point/track  message. 

If  the  aircraft’s  flight  plan  enters  any  restricted  area,  the  aircraft  must  be  rerouted 
laterally  to  avoid  the  restricted  area.  Additional  waypoints  are  inserted  into  the  flight 
plan  to  route  the  aircraft  around  the  area  and  the  new  path  chosen  will  be  one  with 
minimum  distance  laterally  to  be  traveled  by  aircraft.  It  should  be  noted  that  an  aircraft 
whose  flight  plan  calls  for  the  aircraft  to  fly  at  an  altitude  that  is  greater  than  the  ceiling 
of  the  restricted  airspace  is  not  in  conflict  with  the  airspace. 

The  GCU  is  equipped  to  place  the  conflict  circles  around  the  landpoint/tracks  on  the 
Graphic  Display  Terminal  (GDT)  by  a  single  enabling  switch  action. 

It  should  also  be  noted  that  the  Conflict  Avoidance  algorithms  are  only  triggered  upon 
the  generation  of  a  new  flight  path  with  the  Conflict  Avoidance  indicator  enabled.  If 
the  conflict  avoidance  indicator  is  enabled  after  the  generation  of  a  new  path  in  which 
a  conflict  occurs,  the  aircraft  will  continue  to  travel  through  the  restricted  airspace 
unless  FPG  is  called  (by  either  Path  Conformance,  Hazard  Alert,  or  Diversion  Alert). 
Thus,  a  generated  path  is  assumed  conflict  free. 

3.4  Hazard  Alert  (HA)  Algorithm.  HA  is  an  event  driven  task  that  extrapolates  the 
position  of  each  aircraft  that  is  being  reported  on  the  JTIDS  network  for  a  potential 
violation  of  airspace.  HA  provides  an  entry  to  a  HA  table  when  any  two  aircraft  are 
within  hazardous  range.  The  simultaneous  occurrence  of  the  following  is  termed 
“within  hazardous  range”: 

a)  Ground  plane  projections  of  flight  parth  are  within  SAPTHZRG 
nautical  miles  of  each  other,  and 

b)  Altitudes  differ  by  less  than  SAPTHZAL  feet. 
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The  aircraft’s  flight  path  is  linearly  extrapolated  from  its  last  reported  position  and 
velocity.  The  default  values  for  SAPTHZRG  is  3  miles  and  for  SAPTHZAL  is  500  feet. 
The  hazard  alert  will  only  be  triggered  if  the  separation  assurance  indicator  is  enabled 
(SAPTSAIN  =ON). 

HA  is  performed  by  extrapolating  the  position  of  each  aircraft  thirty  seconds  into  the 
future.  An  aircraft  with  a  filed  flight  plan  is  assumed  to  be  following  its  flight  plan  and 
all  other  aircraft  will  be  extrapolated  using  their  current  headings  and  with  altitudes 
that  remain  constant.  Upon  extrapolation  of  each  aircraft’s  position,  each  pair  of 
aircraft  with  at  least  one  aircraft  under  ATALARS  control  will  be  compared  to 
determine  if  a  hazard  (violation  on  each  aircraft’s  airspace)  will  occur  30  seconds  into 
the  future.  If  the  violation  does  exist,  an  entry  is  filed  for  Hazard  Resolution. 

The  HA  Algorithms  are  involved  by  a  periodic  process  in  the  GCU  once  a  second.  HA 
has  been  designed  to  provide  frequent  pairwise  monitoring  of  many  aircraft  without 
imposing  a  heavy  computational  load  on  the  GCU  during  the  Hazard  Resolution 
process. 

HA  is  also  performed  on  aircraft  having  a  new  flight  path  being  generated  and  aircraft 
initially  placed  under  ATALARS  control.  In  these  situations,  the  HA  algorithms  are 
performed  with  an  extrapolation  of  aircraft  position  for  each  second  into  the  future  up 
to  a  period  of  30  seconds.  Those  algorithms  are  modified  for  this  application  to  further 
reduce  the  computational  load  on  the  GCU. 

3.5  Hazard  Resolution  (HR)  Algorithm.  HR  is  scheduled  by  the  HA  algorithm.  In 
conjunction  with  the  FPG  algorithm,  it  generates  hazard-free  flight  plans  for  the 
ATALARS  aircraft  involved  in  a  hazard  alert  condition. 

HR  resolves  an  HA  for  an  aircraft  under  ATALARS  control  by  generating  a  new  flight 
path  for  the  aircraft.  The  destination  LAP  will  remain  the  same  as  it  was  before  the  alert. 
The  first  segment  of  the  path  will  be  generated  within  the  routine.  The  remaining 
portion  will  be  generated  by  FPG.  HR  issues  an  alert  only  when  a  hazard  condition 
detected  between  ATALARS-controlled  aircraft  has  been  resolved. 

HR  generates  a  new  flight  plan  designed  to  avoid  a  collision  between  the  two  aircraft 
detected  by  the  HA  Algorithm.  The  two  aircraft  will  be  separated  by  altitude  equal  to 
twice  the  hazard  threshold  (SAPTHZAL).  For  example,  if  the  hazard  threshold  is  500 
feet,  the  two  aircraft  will  be  separated  by  1000  feet.  The  rules  for  separating  the  two 
aircraft  will  be  as  follows: 

a)  If  both  aircraft  are  under  ATALARS  control,  the  aircraft  traveling 
at  a  lower  altitude  will  descend  to  the  desired  “safe”  altitude 

b)  If  either  of  the  aircraft  mentioned  in  1  (i.e.  both  under  ATALARS 
control)  are  in  an  emergency  situation  (as  detected  by  the  JTIDS 
message),  the  aircraft  under  the  emergency  condition  will  have  priority 
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and  the  other  aircraft  will  be  forced  to  climb  to  a  “safe”  altitude  (if  he 
was  traveling  at  an  altitude  above  the  emergency  aircraft)  or  descend  to 
a  “safe”  altitude  (if  he  was  traveling  at  an  altitude  below  the  emergency 
aircraft).  If  both  aircraft  are  in  an  emergency  situation,  the  rules 
described  in  1  apply. 

3)  If  an  ATALARS  controlled  aircraft  is  in  conflict  with  either  a  non- 
ATALARS  aircraft  or  an  aircraft  not  yet  under  ATALARS  control,  the 
ATALARS  controlled  aircraft  will  either  climb  or  descend  to 
a  “safe”  altitude.  The  GCU  cannot  redirect  an  aircraft  over  which  it 
does  not  have  control. 

With  the  above  rules  intact,  the  aircraft  will  be  redirected  to  avoid  the  hazardous  area 
and  will  continue  along  through  all  of  its  remaining  waypoints  to  the  IAP.  This  is  done 
by  calling  the  FPG  algorithm. 

3.6  Diversion  (DIV)  Algorithm.  DIV  determines  a  new  destination  airbase  for  any 
ATALARS  aircraft  whose  filed  destination  has  been  closed.  DIV  is  enabled  whenever 
an  airbase  status  is  changed  from  open  to  closed.  The  status  is  monitored  by  the  GCU 
net  message  input  processing  function.  When  a  message  is  received  by  the  GCU 
indicating  that  a  given  base  has  been  closed,  DIV  is  called  to  divert  aircraft  to  an 
alternate  airbase. 

DIV  searches  the  airbase  table  for  ATALARS-controlled  aircraft  scheduled  to  land 
at  the  closed  base.  The  aircraft  are  prioritized  according  to  their  Estimated  Time  of 
Arrivals  (ETAs),  with  the  one  have  the  earliest  ETA  given  highest  priority.  For  each 
of  these  aircraft  to  be  diverted,  the  DIV  algorithm  will  assign,  as  its  new  destination, 
the  closest  open  airbase  to  the  aircraft  at  the  time  the  airbase  was  closed.  The  GCU 
will  pass  to  the  FPG  algorithm  the  location  of  the  new  airbase  as  the  IAP  and  the  FPG 
will  generate  a  path  to  this  new  point,  calling  the  HA  and  CA  algorithms  as  requested 
by  the  operator  (SAPTSAIN  and  SAPTCFIN  enabled). 

The  assumptions  taken  by  the  algorithms  are  that  each  aircraft  has  sufficient  fuel  to 
reach  any  open  airbase  to  which  the  aircraft  has  been  routed  and  the  runway  lengths  at 
each  airbase  satisfy  the  requirements  of  each  aircraft  that  is  routed  to  that  airbase. 
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4.0  BRIEF  DESCRIPTION  OF  STGCP  UPGRADE  TO  ISGCP 

The  following  paragraphs  describe  the  major  STGCP  functional  areas  modified  and 
the  functions  added  to  the  STGCP  to  transform  it  into  the  ISGCP  with  simulation 
capabilities  needed  to  create,  control,  and  modify  the  simulated  environment  for  the 
Phase  II  Proof  of  Concept  Demonstration. 

Figure  2  provides  a  description  of  the  upgrades  to  the  STGCP  and  the  Display 
Processor  Computer  Program  (DP CP)  to  generate  the  ISGCP  and  the  GCUCP  respec¬ 
tively.  The  ISGCP  provides  both  an  off-line  and  on-line  environment. 

4.1  On-Line  Processing.  The  ISGCP  has  the  capability  to  communicate  with  the 
GCUCP  over  an  Ethernet  local  area  network  (LAN).  The  ISGCP  sends  status,  JTIDS, 
and  flight  plan  messages  to  the  GCUCP  and  receives  JTIDS  messages  from  the 
GCUCP. 

4.2  Real-Time  Processing.  The  ISGCP  has  the  capability  of  performing  its  processing 
according  to  scheduled  times.  A  built-in  one  second  granularity  clock  is  used  to  trigger 
time-dependent  processing. 


ETHERNET 


1  STATUS.  JTIDS.  FUGHT  PLANS 

GROUND 

1 

CONTROL 

l  JTIDS 

UNIT  (GCU) 

[  INTERACTIVE 
I  SIMULATION 
I  GROUP  (1SG) 


]  TWO  MODES: 

I.  OFFLINE 

1.)  CREATES  SCENARIO  ELEMENT 
DATABASE  {AIRBASES,  AWACS.  F-15s,  ETC.) 
|  AND  FLIGHT  PLANS 

|  2.)  CREATES  MAPS,  FEBAs.  MRCs,  ETC. 

I  3  )  PROVIDES  DATA  REDUCTION  OF 

|  SCENARIO  MESSAGES 


II.  ONLINE 

1 . )  CREATES  SIMULATED  ENVIRONMENT 
BY  GENERATING  AND  TRANSMITTING 
SIMULATED  MESSAGES 

2. )  UPDATES  AND  TRANSMITS  FUGHT  PLANS 

3. )  AUTOMATICALLY  REACT  TO  INCOMING 
MESSAGES 

4  )  PROVIDES  USER  INTERACTION 
WITH  SCENARIO 


ON  LINE 

1 . )  CONTAINS  THE  ATC  ALGORITHMS  THAT  MONITOR  THE 
ATALARS  AIRSPACE  ,  DETECTS  AND  RESOLVES  ATC 
PROBLEMS  OF  PATH  CONFORMANCE,  SEPARATION. 

AND  DIVERSION. 

2. )  PROVIDES  A  TACTICAL  SITUATION  DISPLAY  CONTAINING: 

A. )  ELEMENTS  REPORTING  VIA  JTIDS  MESSAGES 

B. )  MAPS.  FEBA*.  MRCs,  ETC. 

C. )  FLIGHT  PUNS 

D. )  HAZARD  AREAS 

E. )  SPECIAL  ATALARS  SYMBOLOGY  AND  AMPUFICATKDN 
IN  ADDITION  TO  NORMAL  DISPUY  FEATURES 

3. )  PROVIDES  AN  OPERATOR  CONTROL  VIA  A  DISPLAY 
FUNCTION  PANEL  TO  CONTROL  DISPUY  PARAMETERS 
AND  TO  UST  STATUS  AND  DATA  OF  SCENARIO  PARTICIPANTS 

A. )  ALARMS 

B. )  ATALARS  EVENT  LOG. 


5.)  PROVIDES  STATUS  AND  DATA  ON  AC 
AIRCRAFT,  AIRBASES.  FLIGHT  PUNS.  ATAURS 
EVENT  LOG. 


Figure  2.  ATALARS/EJSE  Software  Functional  Diagram 
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4.3  Automatic  Message  Processing.  The  ISGCP  has  the  capability  of  automatically 
generating  outgoing  messages  and  automatically  processing  incoming  messages.  Table 
IV  contains  the  messages  that  are  automatically  processed  by  the  ISGCP. 

4.4  Flight  Plan  Generation.  The  ISGCP  has  the  capability  of  creating  a  flight  plan  entry 
in  the  flight  plan  table  based  upon  an  Air  PPLI  message.  It  then  automatically  creates 
and  transmits  flight  plan  messages  from  the  table  entry  to  the  GCUCP.  The  flight  plan 
entry  values  are  obtained  from  the  simulator’s  database  tables  which  are  created  from 
the  user’s  input  specification  file.  The  input  specification  file  is  a  static  disk  file  that  can 
be  altered  to  prove  the  ATALARS  concept. 

4.5  Dynamic  Data  Base  Update.  The  ISGCP  has  the  capability  to  dynamically  update 
its  database  tables  based  upon  an  operator  input  request  or  upon  receipt  of  newly 
generated  waypoints  received  by  the  GCUCP  on  an  ATALARS-controlled  aircraft. 

4.6  Interactive  Capability.  The  ISGCP  permits  the  operator  to  interact  with  the 
scenario.  The  operator  can  change  the  heading,  altitude,  and/or  speed  of  any  non 
command  and  control  type  Air  PPLI’s.  (These  are  the  aircraft  that  will  come  under 
ATALARS  control  at  some  point  during  the  scenario.)  The  operator  has  the  capability 
to  close  any  open  airbase.  The  operator  also  has  the  capability  to  stop,  or  go 
(resume)/idle  (freeze)  the  scenario  and  to  change  the  time  that  the  ISGCP  will  cease 
processing.  This  will  be  the  main  driver  for  triggering  the  algorithms  described  in 
Section  3.0. 

4.7  Menu  Driven  Keyboard-Printer(KP).  The  ISGCP  contains  a  series  of  menus  and 
screens  arranged  in  top-down  sequence.  These  present  choices  to  the  operator  by 
guiding  him  through  the  possibilities  of  interaction  with  the  scenario  or  offering  the 
status  of  the  scenario. 

4.8  Data  Dictionary  Capability.  The  ISGCP  contains  the  capability  of  obtaining  static 
data  from  a  disk  file  which  has  been  correlated  to  JTIDS-message  field  data.  Specifi¬ 
cally,  the  capability  is  being  used  to  obtain  the  ASCII  description  of  the  airbases 
correlated  to  the  voice  callsign  in  the  Variable  Data  Length(VDL)  1  of  the  Ground 
Station  Status  and  Position  Message,  the  P2  message.  The  capability  is  also  being  used 
to  obtain  an  alternate  airbase  to  correlate  to  the  Track  Number  Source  (TNSC)  that  is 
stored  in  the  flight  plan. 

4.9  Report  Generation.  The  ISGCP  has  the  capability  of  recording  ATALARS  mes¬ 
sages  and  writing  them  to  the  line  printer  at  the  completion  of  the  scenario.  It  also  has 
the  capability  of  presenting  status  and  data  screens  at  the  System  Control  Console 
(SCC).  The  screens  that  are  available  list  the  status  of  an  airbase,  all  non-Command 
and  Control  Air  PPLI  elements,  all  units  that  have  been  reported  on  via  an  Air  PPLI 
message,  a  count  of  all  the  messages  that  have  been  sent  between  the  ISGCP  and 
GCUCP,  and  a  log  of  all  the  ATALARS  events  that  have  taken  place  during  the 
scenario. 
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TABLE  IV 


ISGCP  AUTOMATIC  MESSAGE  PROCESSING 


ISGCP  INPUT 

MESSAGE  PROCESSING 

_ l 

MESSAGE  RECIEVED 

PROCESSING  PERFORMED 

M3-1  AIRCRAFT 

ASSIGNMENT 

UPDATE  FLIGHT  PLANS 

AND  DATABASE 

J10.3  HANDOVER  MESSAGE 

ACKNOWLEDGE  RECEIPT 

ISGCP  OUTPUT  MESSAGE  PROCESSING 

MESSAGE  TRANSMITTED 

^  ] 

PROCESSING  PERFORMED  1 

FLIGHT  PLAN 

1 

j 

CREATE  AND  TRANSMIT 

FLIGHT  PLAN  MESSAGE 

M3-1  AIRCRAFT 
ASSIGNMENT 

L 

ACKNOWLEDGE  RECEIPT 

MESSAGE 

DESCRIPTION 

SIMULATION 

USE 

J  2  2 

AIR  PPLI 

AWACS.  ATALARS 

AC  FT  (F-15S,  ETC.) 

J  3.2 

AIR  TRACK 

NON  JTIDS  EQUIPPED 

ACFT  (COMMERCIAL 

AIRLINES.  HOSTILES.  ETC) 

J  3.5 

LAND  (GROUND)  POINT/TRACK 

SAM  SITES 

J  10.3 

HANDOVER 

TRANSFER  CONTROL  OF 

ACFT  BETWEEN  AWACS 

AND  GCU 

J  13.2 

AIR  PLATFORM  &  SYSTEM 

STATUS 

PROVIDE  PLATFORM 

STATUS  OF  J 2.2  TYPE 
ELEMENTS 

P  2 

GROUND  STATION  POSITION 

AND  STATUS  REPORT 

AIRBASES 

FLIGHT  PLAN 

FLIGHT  PLAN  DATA 

FLIGHT  PLAN  FOR 

ATALARS  ACFT 
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5.0  RESULTS  AND  RECOMMENDATIONS 

To  demonstrate  each  of  the  ATC  algorithms  developed  under  the  ATALARS  SBIR,  a 
scenario  depicting  a  conventional  conflict  in  the  NATO  theatre  consisting  of  24 
airborne  elements  was  design.  Each  element  was  reported  via  an  Air  PPLI  (J2.2)  or 
track  message  (J3.2)  and  ten  NATO  airbases  were  reported  via  P2  messages.  Voice 
callsigns  and  airbase  status  were  reported  using  VDLs  1  &  5  to  the  P2  messages.  The 
airborne  elements  were  a  mix  of  friendly,  neutral,  and  hostile  aircraft  with  those  aircraft 
under  ATALARS  control  visually  identified  by  a  subscripted  “AC”  for  ATALARS 
control.  Those  friendly  tracks  not  under  ATALARS  control  but  in  voice  contact  with 
the  ATALARS  GCU  were  identified  by  a  subscripted  “AV”  for  ATALARS  voice. 
Through  the  ISG,  an  operator  or  a  member  of  the  audience  could  alter  the  heading, 
airspeed,  or  altitude  of  a  pre-  scripted  scenario  element  under  ATALARS  control.  This 
provided  the  means  to  verify  each  of  the  ATC  algorithms  during  the  demonstration. 

5.1  Results.  The  Proof  of  Concept  demonstration  showed  conclusively  that  JTIDS 
messages  could  be  employed  in  an  ATC  environment  to  resolve  ATC-type  conflicts 
and  hazards.  Specifically,  the  demonstration  proved  that  through  the  use  of  existing 
TADIL-J  PPLI  messages,  the  track  of  an  element  under  ATALARS  control  could  be 
continuously  monitored  for  path  conformity,  conflict  avoidance,  and  hazard 
alert/avoidance.  The  GCU  provided  the  operator  with  an  audible  and  visual  alert  when 
deviations  exceeded  defined  thresholds.  Additionally,  without  operator  action,  algo¬ 
rithms  in  the  GCU  automatically  determined  the  best  solution  to  the  ATC  problem, 
and  GCU-generated  M3-1  assignment  messages  were  automatically  transmitted  to 
each  applicable  aircraft  resolving  any  deviation,  conflict,  or  hazard. 

5.1.1  Path  Conformance  Demonstration.  To  demonstrate  the  GCU’s  ability  to  detect 
an  aircraft’s  deviation  from  its  filed  flight  plan,  a  member  of  the  audience  selected  at 
random  an  aircraft  under  ATALARS  control.  The  aircraft’s  heading,  altitude  or  speed 
was  dynamically  changed  to  force  a  violation  of  the  path  conformity  lateral,  vertical  or 
time  threshold.  As  soon  as  the  threshold  was  exceeded,  the  GCU  issued  an  alarm 
notifying  the  operator  of  a  path  conformance  violation.  The  GCU  then  generated  and 
transmitted  an  M3-1  assignment  messages  directing  the  aircraft  back  to  its  filed  flight 
plan  and  ensured  the  new  flight  plan  was  conflict-free  to  its  filed  destination  and 
hazard-free  for  the  next  thirty  seconds.  Once  established  on  a  new  flight  plan,  hazard 
alerting  guaranteed  safe  separation  between  an  aircraft  under  ATALARS  control  and 
all  other  known  traffic  until  hand-off  to  an  arrival  controller.  To  demonstrate  complete 
GCU  autonomy  and  proper  algorithmic  functionality,  path  conformance  was 
demonstrated  with  the  algorithm  enabled  and  then  disabled.  With  the  path  confor¬ 
mance  algorithm  disabled,  no  algorithms  were  invoked,  no  actions  were  taken  by  the 
GCU,  and  the  affected  aircraft  would  continue  to  deviate  from  its  filed  flight  plan.  With 
the  algorithms  enabled,  the  deviation  was  detected,  reported,  resolved,  and  the  affected 
aircraft  returned  to  its  filed  flight  plan  at  or  prior  to  its  next  waypoint. 

5.1.2  Diversion  Demonstration.  An  airbase  was  selected  at  random  by  a  member  of  the 
audience  and  “closed”.  Upon  the  next  transmission  of  its  P2/VDL5,  an  alarm  was  issued 
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for  each  aircraft  under  ATALARS  control  with  that  airbase  as  its  filed  destination.  This 
portion  of  the  demonstration  proved  that  the  status  of  all  reporting  airfields  was  being 
continuously  GCU-monitored  and  each  affected  element  under  ATALARS  control 
would,  independent  of  operator  action,  be  automatically  transmitted  a  GCU-con- 
structed  route  of  flight  to  the  nearest  suitable  alternate  immediately  upon  closure  of 
its  intended  destination.  Again,  the  new  route  of  flight  would  be  conflict  free  to  the 
alternate  airfield  and  hazard  free  for  the  next  thirty  seconds. 

5.1.3  Conflict  Avoidance  Demonstration.  The  ability  of  the  GCU  to  construct  routes 
of  flight  around  restricted  airspace  was  demonstrated  in  conjunction  with  diversion. 
With  the  conflict  avoidance  algorithm  disabled,  a  selected  airbase  was  closed  at  such  a 
time  as  to  place  an  area  of  restricted  airspace,  defined  with  a  J3.5  message,  directly 
along  a  route  generated  from  the  aircraft’s  present  position  direct  to  the  nearest 
suitable  alternate.  The  airbase  was  then  closed,  the  GCU  constructed  a  route  of  flight, 
and  the  route  of  flight  was  then  displayed  to  the  operator.  It  penetrated  restricted 
airspace.  The  scenario  was  repeated  with  the  conflict  avoidance  algorithm  enabled  and 
the  airbase  was  once  again  closed.  The  new  flight  plan  was  then  displayed  and  the 
intended  route  of  flight  was  around  the  restricted  airspace.  In  most  instances,  the  GCU 
constructed  multi-segment  routes  of  flight  around  restricted  airspace  to  minimize  flight 
time.  In  the  remaining  cases,  a  single  point  was  sufficient  to  provide  minimum  flight 
time. 

5.1.4  Hazard  Avoidance.  Most  significantly,  the  Proof  of  Concept  scenario 
demonstrated  that  a  pre-scripted  mid  air  collision  would,  prior  to  the  involved  aircraft 
reaching  “near  miss”  criteria,  be  detected  and  averted  with  no  operator  intervention 
or  action  required.  To  demonstrate  this,  a  point  shortly  after  takeoff  was  selected  and 
two  aircraft  were  scripted  to  be  at  that  point  at  the  same  time  and  at  the  same  altitude. 
Again  the  demonstration  was  conducted  with  and  without  the  hazard  algorithm 
enabled.  Without,  the  aircraft  appeared  to  collide  —  their  positions  became  coincident. 
With  the  algorithm,  one  of  the  involved  aircraft  was  directed  to  descend  1000  feet  (twice 
the  altitude  threshold)  when  the  hazard  was  detected.  The  display  of  tabular  data  at  the 
Display  Function  Panel  confirmed  the  altitude  of  the  vectored  aircraft  decreasing  at 
each  reporting  interval  until  it  reached  its  assigned  altitude.  Additionally,  the  scenario 
demonstrated  that  an  operator  would  not  be  notified  a  potential  collision  had  been 
resolved  until  the  aircraft  had  a  minimum  of  a  1000  feet  separation. 

5.2  Recommendations.  Though  the  Proof  of  Concept  demonstration  proved  the  opera¬ 
tional  utility  of  JTIDS  messages  in  an  ATC  role,  it  became  very  apparent  the  current 
message  set  used  by  the  Air  Force  lacked  many  of  the  operational  parameters  needed 
to  convey  data  required  by  a  aircrew  to  successfully  complete  their  mission  in  an 
all-weather  environment.  Specifically,  many  of  the  items  provided  an  aircrew  via 
Automatic  Terminal  Information  Service  (ATIS)  or  Flight  Information  Publications 
(FLIP)  were  not  available  in  the  current  message  structure.  Table  V  is  a  list  of  the  types 
of  data  currently  provided  by  ATIS  or  FLIP  documents  which  are  required  for  flight. 
The  list  is  not  intended  to  be  exhaustive,  but  rather  a  subset  of  items  that  must  be 
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TABLE  V 

ATALARS  UNIQUE  MESSAGE  FIELDS 


^^'^PHASE^ 

DATA 

DEPTARTURE 

ENROUTE 

ARRIVAL 

PV 

X 

X 

RVR 

X 

i 

X 

RSC 

X 

X 

CEILING 

X 

X 

RCR 

X 

X 

PRECIP 

X 

X 

X 

W/V 

X 

X 

X 

ALTSTG 

X 

X 

X 

TURB 

X 

X 

X 

ICING 

X 

X 

X 

:  ALS 

X 

X 

X 

MEA 

X 

MAA 

X 

!  MRA 

i  X 

X 

X 

1  MCA 

X 

X 

X 

j  RWY 

X 

X 

1  GS 

X 

TCH 

X 

DH 

X 

MDA 

X 

!  HAT 

X  1 

HAA 

X 

1  AFLD  STAT 

X 

X 

x  ! 

DEST 

!  X 

X 

X 

1  ALT 

X 

X 

X  1 

IAF 

X 

I  FAF 

X 

MAP 

X 

GSIA 

X 

FAS 

X 

TA 

X 

VDP 

X 

AFLD  LTG 

1 

X 

X 

considered  in  an  autonomous  ATC  environment  and  any  further  study  of  JTIDS 
message  traffic  for  ATC  functions. 

The  final  recommendation  for  any  future  ATALARS  exploration  is  one  of  processing 
requirements.  Admittedly,  the  Proof  of  Concept  scenario  was,  by  design,  on  a  greatly 
reduced  scale  with  only  24  dynamic  elements  under  ATALARS  control.  Even  at  this, 
given  the  complexity  of  the  ATC  algorithms  and  the  need  for  continuous  path,  conflict, 
and  hazard  monitoring,  the  limits  of  the  Ethernet  LAN  were  approached.  In  an 
operational  environment,  ATALARS  could  conceivably  support  upwards  of  1000 
aircraft.  To  handle  such  a  dense  environment  will  require  considerably  greater  process- 
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ing  capabilities  such  as  those  provided  by  top-end,  commercially-available  worksta¬ 
tions.  As  the  need  to  demonstrate  increased  traffic  handling  capabilities  increases,  so 
does  the  need  for  increased  operator  interfaces.  In  a  workstation  environment,  the 
operator  can  be  provided  with  greater  real-time  control  of  participating  elements 
thereby  demonstrating  even  more  conclusively  the  feasibility  of  secure,  jam-resistant 
data  links  for  autonomous  control  of  a  conventional  conflict’s  air  traffic  control  require¬ 
ments. 
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6.0  LIST  OF  ACRONYMS 


ACSI  Analysis  &  Computer  Systems,  Inc. 

AFLD  LTG  Airfield  Lighting 

AFLD  ST  AT  Airfield  Status 

ALS  Approach  Light  System 

ALT  Alternate 

ALTSTG  Altimeter  Setting 

ATALARS  Automated  Tactical  Aircraft  Launch  and  Recovery 
System 

ATC  Air  Traffic  Control 

ATIS  Automatic  Terminal  Information  Service 

CA 

CPU 

Conflict  Avoidance 

Central  Processing  Unit 

DEST 

DH 

DIV 

DPCP 

Destination 

Decision  Height 

Diversion 

Display  Processor  Computer  Program 

EJSE 

ETA 

Enhanced  JTIDS  System  Exerciser 

Estimated  Time  of  Arrival 

FAF 

FAS 

FLIP 

FPG 

Final  Approach  Fix 

Final  Approach  Speed 

Flight  Information  Publication 

Flight  Path  Generation 

GCUCP 

GDT 

GS 

GSIA 

Ground  Control  Unit  Computer  Program 

Graphic  Display  Terminal 

Glide  Slope 

Glide  Slope  Interception  Altitude 

HA 

HAA 

HAT 

HR 

Hazard  Alert 

Height  Above  Airport 

Height  Above  Touchdown 

Hazard  Resolution 

IAF 

IAP 

ISG 

ISGCP 

Initial  Approach  Fix 

Initial  Approach  Point 

Interactive  Simulation  Group 

Interactive  Simulation  Group  Computer  Program 

JTIDS 

Joint  Tactical  Information  Distribution  System 
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LAN 

MAA 

MAP 

MCA 

MDA 

MEA 

MRA 

PCA 

PPLI 

PRECIP 

PV 

RCR 

RSC 

RVR 

RWY 

SA 

SBIR 

SCC 

STGCP 

TA 

TCH 

TNSC 

TURB 

VDP 

VDL 

w/v 


Local  Area  Network 

Maximum  Authorized  Altitude 
Missed  Approach  Point 
Minimum  Crossing  Altitude 
Minimum  Descent  Altitude 
Minimum  Enroute  Altitude 
Minimum  Reception  Altitude 

Path  Conformance  Alert 

Precise  Participant  Location  and  Identification 

Precipitation 

Prevailing  Visibility 

Runway  Condition  Reading 
Runway  Surface  Condition 
Runway  Visual  Range 
Runway 

Separation  Assurance 

Small  Business  Innovation  Research 

System  Control  Console 

Simulation  Tape  Generation  Computer  Program 

Transition  Altitude 
Threshold  Crossing  Height 
Track  Number  Source 
Turbulence 

Visual  Descent  Point 
Variable  Data  Length 

Wind  Velocity  (Direction  &  Speed) 
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7.0  GLOSSARY  OF  ATC  DEFINITIONS 

ATALARS  Control  Area  -  An  airspace  region  under  control  of  an  ATALARS  GCU. 

Conflict  -  An  ATC  state  in  which  an  aircraft  will  be  redirected  so  as  not  to  penetrate 
a  restricted  fixed  airspace. 

Diversion  -  The  reassessment  of  a  controlled  aircraft’s  original  filed  destination  to  a 
new  designated  destination. 

Hazard  -  An  ATC  state  in  which  an  aircraft  is  in  such  proximity  to  another  aircraft  as 
to  require  immediate  action  to  avoid  collision. 

JTIDS  Equipped  Aircraft  -  Aircraft  under  control  of  an  ATALARS  GCU.  In  this 
JTIDS  feasibility  study,  ATALARS  aircraft  are  also  JTIDS  equipped. 

Path  Conformance  -  The  assessment  of  a  controlled  aircraft’s  actual  route  of  flight 
compared  with  its  filed  flight  plan. 

Restricted  Airspace  -  Designated  airspace  that  may  not  be  penetrated  by  controlled 
aircraft  without  clearance  from  the  controlling  ATC  agency.  (Restricted  airspace 
includes  warning,  danger,  and  prohibited  areas). 

Separation  Assurance  -The  process  of  assuring  that  ATC  states  of  hazard  will  not  occur 
without  a  response  from  the  controlling  authority. 
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